Along with the development of mobile network services and automatic control technologies, a machine type communication mode, also referred to as a Machine to Machine (M2M) communication mode, has appeared. In this communication mode, at least one party involved in the communication is a machine device.
A narrow definition of the M2M is machine to machine communication, but in a broad sense, the M2M includes networked applications and services centred on intelligent interactions of a machine terminal. The M2M is based on an intelligent machine terminal, and may provide a user an information-based solution using a plurality of communication modes as access means to satisfy an information-based demand of the user for aspects such as monitoring, commanding and scheduling, data collection and measurement. The M2M may be applied to industry applications, household applications, personal applications and the like.
An object to which the M2M communication is directed is a machine, and communication behaviours are controlled automatically, that is, initiation and termination of the communication and control over some admittances and limitations during the communication are all automatic behaviours. Such behaviours depend on restriction and control of behaviours of the machine (i.e., the terminal in M2M communication) in the M2M communication. Behaviours of the terminal in the M2M communication are restricted by service subscription data, and a network manages the terminal in the M2M communication according to the service subscription data.
The most typical communication mode in the machine type communication is communication between the terminal and an application server, wherein the terminal is referred to as an MTC device, and the application server is referred to as an MTC server.
In the case of 2G/3G/LTE access, the M2M communication mainly uses a Packet Service (PS) network as an underlying bearer network to implement service layer communication between the MTC device and the MTC server. FIG. 1 is a schematic diagram of the architecture for an M2M communication entity to access an Evolved Packet System (EPS) according to a relevant art. As shown in FIG. 1, the underlying bearer network includes: an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a Mobility Management Entity (MME), a Serving Gateway (S-GW or SGW), a Packet Data Network Gateway (PDN GW, or P-GW, or PGW), a Home Subscriber Server (HSS), and a Policy and Charging Rules Function (PCRF) entity. Wherein, a main network element of the E-UTRAN is an evolved base station (Evolved NodeB, eNodeB, or eNB).
In FIG. 1, the MME is in charge of work related to a control plane such as mobility management, processing of non-access-layer signalling, and context management in user mobility management and the like. The S-GW is an access gateway device connected with the E-UTRAN, and is in charge of forwarding data between the E-UTRAN and the P-GW, and caching paging-waiting data. The P-GW is a border gateway of the EPS and a Packet Data Network (PDN), and is in charge of functions such as access of the PDN, and data forwarding between the EPS and the PDN. The PCRF is the Policy and Charging Rules Function entity, and is connected with an operator Internet Protocol (IP) service network via a receiving interface Rx to acquire service information, and the PCRF may also be connected with a gateway device in the network via a Gx interface, and is in charge of initiating IP bearer establishment, ensuring Quality of Service (QoS) of service data, and performing charging control. The HHS is used for managing subscription data of the user, and managing important context information of the user when accessing the network.
In addition, the MTC server may play the role of an Application Function (AF), and may be connected with the PCRF via the interface Rx to implement control over the bearer. Furthermore, the MTC server may play the role of an SIP AS, and may be connected with the HSS via an Sh interface to access application service data.
In FIG. 1, an MTC UE accesses an EPS network via the E-UTRAN (eNodeB). After being allocated with an IP address, the MTC UE may establish an IP channel with the MTC server, so as to implement upper-layer service communication with the MTC server. The IP channel established between the MTC UE and the MTC server is a logical IP channel.
At present, one way of implementing the M2M communication is to establish, on the IP channel between the MTC UE and the MTC server, a service layer interface protocol, through which the MTC UE server performs service data interaction with the MTC server, and the MTC server also implements control over the MTC UE.
Data communication between the MTC UE and the MTC server may be implemented via IP connection between the MTC UE and the MTC server. However, a demand for MTC monitoring is hard to be implemented on the IP connection: the MTC server needs to monitor an operational state of the MTC UE and dynamically learn the current state of the MTC UE in time, and when there is a change in the current state of the MTC UE, the MTC server needs to be informed timely. These changes in the state of the MTC UE may include: attachment of the MTC UE from the network, entering of the MTC UE into a non-connection state, releasing of a wireless connection by the MTC UE, and a change in the current location of the MTC UE. These changes in the state of the MTC UE may be referred to as MTC events. An MTC event to be monitored may generally be defined in MTC subscription data of an HLR/HSS, and be issued to a Serving GPRS Support Node (SGSN)/MME by the HLR/HSS through a flow of attachment of the MTC UE to the network. And detection of the MTC event generally needs to be performed by a network entity of a core network. For example, in the EPS network, a network element in charge of detecting the MTC event may be the MME/SGW/PGW or the like; and in a GPRS network, the network element in charge of detecting the MTC event may be the SGSN/GGSN and the like. When detected, the MTC event generally needs to be reported to the MTC server, so that the MTC server learns the operational status of the MTC UE in time.
Network sharing may provide a capability of sharing a same network node by Public Land Mobile Networks (PLMN) of multiple operators, avoid repeated network construction in a same area, and save network construction costs of the operators. In the shared network, an overloaded core network node sends an overload message to an access network node. After receiving the overload message, the access network node will not select the core network node as a serving node for the terminal, but select another useable network node instead. If there is no useable network node, the access network node will reject an access request of the terminal, or broadcast an Access Class Barring (ACB) parameter. When a load of the core network node becomes normal, the core network node sends an overload ending message to the access network node, which may then continue to select the core network node as the serving node for the terminal. However, the above technology does not distinguish the PLMNs in performing access control, and the terminal of an operator that does not cause overload of a shared network node is also treated in the same way, failing to ensure a fair access control over terminals of all PLMNs sharing the network.